The work environment of the process designer is the docuRob ® WorkFlow process modeler product, which allows for the construction of graphical process models compliant with the guidelines of the OMG BPMN v. 2.02 standard. In accordance with the adopted design methodology, the tool can be used in individual phases of the project life cycle from the conceptual process model to its executable definition.
The executable process definition is made available in a process repository maintained within a tool integrated with the docuRob ® WorkFlow execution platform. The process definition repository provides flexible management that allows versioning of definitions and controlled release of them into operation. The platform allows simultaneous processing of processes initiated on the basis of different versions of their definitions.
In the following sections of the chapter we discuss individual classes of process model objects (flow objects) used to create subsequent levels of the process model.
Process Description
Process Definition is a complete representation of a process that enables its execution by a process management system. The process definition concerns various aspects of the process, in particular: control flow, data flow, assignment of participants, and invocation of applications within an activity.
Modifying a process definition creates a new version of the definition. Multiple versions of the same process can exist (and be executed) at any given time, but only one is the most current, available, and will be executed for all newly started processes. A process definition can also be part of another, more complex process.
A process (its definition) may require input parameters and produce the results of execution in the form of output parameters. The tabs of the process definition screen are presented in Figure 1.
Name is a unique identifier of a process definition within a given docuRob®WorkFlow installation, with the subsequent versions of the definition being identified by integers starting from 1.
The priority determines the level of preference for all process instances started at the level of this definition. The priority can be defined both at the process level and at the definition level activities. The default value of the indicator is 100 and its maximum value is 2147483647. A process definition called as a subprocess can inherit the priority of the corresponding compound activity or keep its own.
The availability date informs about the date when the process is made available and defines the beginning of its usage period, while the expiration date specifies the time until which new process instances can be created based on this definition.
Process execution information determines the maximum instance processing time of the process and indicates the person who receives the message about exceeding this limit. The execution time of the process instance is determined as the number of days and hours from the moment the process instance is launched. Exceeding the defined time causes the entire process instance to be delayed. Additionally, it is also possible to define a rule for selecting employees who should be notified in the event of a delay. This rule has the same limitations as the rules for selecting participants in activities.
The Reminder tab allows you to set a warning time frame, also with the precision of days and hours, about the obligation to start handling the task. Potential task performers are selected based on the BPQL expression of the assignment of performer(s) (Work Participant Assignment [WPA]). The task acceptance restriction defined at the process level applies to all tasks performed by process participants.
Process owner identifies the person responsible for its maintenance and operation and most often for all aspects related to the business activity it supports. Users acting in this role usually receive all the standard messages regarding exceeding the limits.
An alternate participant, also designated by a BPQL expression, takes over task executions that exceed specified execution time constraints expressed as a period of time preceding the task's scheduled completion date.
Event parameters are used in events that handle exceptional situations through BPQL rules. This allows for flexible assignment of values to individual parameters of the invoked applications. The BPQL rules used for assignments have one limitation: they must return a value type that is compatible with the argument type of the invoked application
Time constraints for opening tasks define the maximum time from the creation of a task on the list or lists of potential performers to the start of the task. As in previous cases, a designated person will be notified when this limit is exceeded.
Activities
An activity is a work unit that specifies a single step within a process. An activity can be atomic, compound, or control. An atomic activity is defined as a task, a compound activity as a subprocess, and a control activity as a gate.
The order of workflow between activities is defined by the type and conditions of the selection of the appropriate transition. Each activity can have preceding activities and immediately following activities.
Within the definition of activities, we can determine their kind by inserting appropriate activity type marker in the graphical activity symbol. Rules for their co- occurrence in the definition of an activity and the meaning are given in Table 1 and Table 2.
| marker | Co-occurring markers | ||||
|---|---|---|---|---|---|
| Loop | Sequential loop | Parallel loop | Ad-hoc | Compensation | |
| Loop | X | Y | |||
| Sequential loop | X | Y | |||
| Parallel loop | X | Y | |||
| Ad-hoc | Y | Y | Y | X | Y |
| Compensation | Y | Y | Y | Y | X |
Table 1. Rules for using Activity Type Markers in metadata
Figure 1. Process definition tabs
Groups of activity metadata, common to child model objects and shared through the inheritance hierarchy, are presented in this section. The remaining metadata elements are discussed in the task and subprocess sections, respectively. Additionally, a separate section is devoted to describing the Ad hoc subprocess due to its specific nature.
General information includes elements such as the name of the activity and the activity number within the process model being created. For the activity User, Service, Script, and Subprocess are defined markers of the type of activity listed in Table 2. The Description field allows one to create activity documentation, which can optionally be made available to users of the process instance performing this task.
| Indicator | Name | Description |
|---|---|---|
 | Loop | The activity is executed in a loop until the value of the variable controlling the termination of the loop changes to the logical value ’true'. The logical variable is initialized to the value ’false’ prior the execution of the activity instance. The termination condition is defined as a BPQL conditional expression placed in the post-action tab. |
 | Sequential loop | The sequential loop declaration for a multi-instance kind causes the processed activity instances to be executed sequentially. Each instance is executed separately for each participant contained in the result set of the BPQL expression designating the list of participants. |
 | Parallel loop | The parallel loop declaration for a multi-instance kind causes concurrent execution of processed activity instances. The instance is executed separately for each participant contained in the result set of the BPQL expression specifying the list of participants. |
 | Ad-hoc | Task and subprocess definitions. The Ad hoc tag used in the subprocess symbol means that all activities of this subprocess that are not restricted by the flow can be performed based on the Ad hoc discipline. This means that all such User type tasks occurring within this subprocess can be performed multiple times by all users designated for them by the BPQL expression. Ad hoc task or subprocess instances are activated together within the containing process/subprocess instance. An Ad hoc task instance is terminated by the task termination condition. Ad hoc subprocess instance is terminated when the following conditions are met: All process task instances are completed. The termination condition of the Ad hoc instance is true, i.e. the BPQL conditional expression evaluates to ‘true'. |
 | Compensation | The compensation indicator denotes an activity that reverses the effects of its related activities, i.e. a task or a subprocess. The association of the compensated activity is specified with the use of an appropriate boundary event of the kind ‘compensation’ associated by an association with the compensating activity. The condition for performing compensation is a positive completion of the reversed activity. If such a condition does not occur for the indicated activity, then compensation is not performed. |
Table 2. Tags indicating the kind of activity
In the lower right corner of the form there are two function keys that allow one to:
- Approval definition of activity according to the control depth specified in the Tool Options.
- Cancel ends the activity definition
Figure 2. Metadata of the action object type
Within the Performer, Post-action and Pre-action tabs there is a BPQL expression helper, available via the Insert service, which supports the selection of appropriate expression elements from the provided dictionaries (see Figure 3.).
Figure 3. BPQL Expression Helper
The selection of the process execution path is based on the definition of the configuration of incoming and outgoing flows from activities or gateways. The instantiation of process graph elements involves the use of tokens flowing between them or in the case of events on generating or receiving event triggers. The concept of a token was introduced as an intuitive illustration of the mechanism for transferring control between elements of a process graph.
Logical dependencies between incoming flows within the activity metadata allows for adopting the desired instantiation discipline for a given process graph element and, in the case of outgoing flows, for selecting the succeeding path of the token flow. The definitions of the join and the split flow discipline is shown in Figure 4.
Joining of input control of multiple incoming flows, or in other words handling of multiple incoming tokens to an activity, depends on the specified operator causing for:
- AND operator instances actions after tokens have been entered by all incoming flows
- OR operator instances actions after the tokens have entered all incoming flows that meet the conditional expression defined for them
- XOR operator instances activities after any of the incoming flows receives the first token.
Control flow of multiple outgoing flows, or in other words handling of multiple outgoing tokens from an activity, depends on the specified operator causing for:
- AND operator sending tokens through all outgoing flows
- OR operator sending tokens by all outgoing flows that satisfy the conditional expression defined for them
- XOR operator sending tokens via the first outgoing flow that satisfies the conditional expression defined for it or is not limited by any condition
Figure 4. Join and split flow parameters
An alternative technique for controlling selection of a process path is gateways, which, in addition to providing greater flexibility in the selection of a process path, are essential elements of the conceptual process model. Flow control using gateways is described in detail in the following sections of the documentation. Because of their visibility in the process/subprocess graph, gateways are the preferred technique for defining branches, at least at the level of the conceptual process model.
Regardless of the type and kind of action, the possibility of executing a BPQL script or an external application has been introduced*,* both before its execution (Pre-action) and after its execution (Post-action). The interfaces for entering a BPQL script are shown in Figure 5 and Figure 6 respectively.
Figure 5. Pre-action Definition activities
Actions allow for:
-
performing additional actions on process input and output parameters, global variables or parameters of the application called in the activity (e.g. setting status, adding a value to the loop counter, etc.)
-
invoking additional applications before starting and at the end of an activity.
Actions are performed:
-
when an activity is assigned to a given performer. This action is called preaction.
-
at the completion time of the activity (does not apply to interrupting of the activity). This action is called postaction.
An action is represented as a BPQL expression or as an invoked application. In the case of the BPQL rule, unlike the participant assignment or a transition condition, there are no restrictions on the value returned by the BPQL rule executed in the action.
Actions are most often used to properly prepare input and output parameters of the application called in the activity. Another application of the action is to use it to set the values of process data represented by global variables.
To define Preaction you need to:
- in the process list panel, click on the process in question,
- go to the ’Model’ tab of the process in the right panel. Find the right activity and double-click. The activity properties dialog will appear on the screen,
- click on the Pre action node.
- Select the appropriate Action Type.
- If the selected type is BPQL – the appropriate BPQL rule must be defined. If the application has been selected, then the specification of its invocation must be provided as when defining the application.
For the Pre-Action script, it is additionally possible to execute it in whole or in part before execution of the activity instance by marking it as a @beforePreAction block.
The code contained in this block, unlike the rest of the Pre-action, will be executed during the creation of the activity instance. In a situation where n is defined for performers of a given activity, the @beforePreAction block will be executed n times during the creation of the activity (n instances of the activity are created*),* while the remaining part of the pre-action will be executed once, immediately before the activity is executed.
The postaction is defined in a similar way by selecting the Post-action node.
Figure 6. Definition of Post-action activity
In the case of complex processes with high variability of types of supported use cases, an important element of the process environment definition is to designate appropriate human resources for User type tasks. One of the elements of parameterization of the Analytical Simulator used for this purpose is to determine the performance parameters of each activity.
Figure 7 presents the interface for describing such activity performance parameters as the number of potential participants and the average task completion time. Optionally, you can also provide the average task completion costs.
Analytical Simulator algorithm and an example of its application in process design and management is available in the section on process monitoring and analysis.
Figure 7. Analytical simulator parameters for the activity
Task
A task is an indivisible element of the model, unlike a subprocess, which may contain an arbitrarily complex model encompassing many elements. Task types, along with their graphic symbols and description of the activity, are presented in Table 3.
| Symbol | Name | Description |
|---|---|---|
 | Message | Task sends a message containing metadata and the message content via the invoked communication application (e-mail, electronic messenger, SMS). The parameters placed in the process container are transferred to the communication Application in accordance with the requirements adopted for the Service type task. |
 | Reception | Task listens for a trigger thrown by its corresponding throwing task Message. Handling the message requires invoking an appropriate application that is compatible with the application used in the throwing task. In the case of an event-driven gateway the task appears as one of the events indicating the outgoing flow. |
 | User | The task participant is an authorized User who has received information about a new task on his task list. The interface, along with the appropriate services, is provided by an application called by the workflow engine. The docuRob®WorkFlow engine supports the user interface via an integrated electronic forms module invoked by default as a standard application provided a form is defined for the process type.. The assignment of a task to one or more users is controlled by a BPQL script that uses such features of potential performers as authorizations, competences, position and function in the organizational structure or a role in the business process. |
 | Manual | The task is made available via the task list to the appropriate user or users but is not managed in any way by the workflow engine except for marking tracked time points including start and end times |
 | Business rule | Task performed automatically based on BPQL conditional expressions. Conditional expressions contain global process variables, local script variables, data from external databases and/or elements of XML files. The result of the operation is setting the values of the appropriate global process variables. |
 | Service | The task is performed by an available Web Service or by an Application called directly by the workflow engine. The called applications are responsible for handling the user interface and can be implemented in any programming language. |
 | Script | The task is performed by a BPQL script operating on process container data, process ontology variables, and external data sources. |
Table 3. Task object types.
Application call specification defines how a given application is to be invoked within a task. This also includes specifying rules for mapping input and output parameters of a subprocess.
Figure 8. Definition of parameters of the Application handling the task object
The Application Parameter Mapping (Table 4) specifies how to:
- assign a value to the application input parameters performed as part of the activity,
- assign a global variable to which the results of executing the activity application will be passed*.*
The BPQL rules are used to define the mappings. The attributes of the parameter mappings are described in Table 4.
The Application Definition is required for User and Service task types and it is optional for Activity type Message and Reception as well as Business Rules. In the first case, it is possible to use external software (e-mail, SMS gateway, messenger) and in the second case, in addition to the BPQL rules, one can use an external rule engine such as Drools.
| Attribute name | Attribute description |
|---|---|
| id | Mapping identifier. |
| Name | The name of the application attribute to which the mapping applies. |
| Value | A BPQL rule representing a mapping. |
Table 4. Application parameter mapping attribute specification
Figure 9. Application parameter value mapping form
The docuRob®WorkFlow system supports three call protocols:
- Java – the application implements the external application interface defined in the docuRob® WorkFlow system and is implemented as a Java class. This protocol works only in synchronous mode. The service field specifies the full location of the class (packages and class name).
- URL – the application is invoked using a URL address available via the HTTP protocol. This protocol is primarily characterized by invoking an action and works only in synchronous mode. The Service field specifies a specific invocation address. This protocol is also used to invoke the REST (Representational State Transfer*) services*.
- WebService – an application is a web service that provides one or more operations. The application specification can be downloaded from a UDDI server (Universal Description, Discovery and Integration) or directly from a WSDL file. After reading the specification of a given service, a list of input and output parameters is automatically loaded. This protocol characterizes the invocation of an automatic action and works in asynchronous mode. The Name field specifies the name of the service and the Service field specifies the name of the invoked operation in this service. The service specification can use the SOAP or REST protocol.
Figure 10. Example definition of Application parameters for calling the SOAP service
To specify the location of the WSDL, select the button marked with a green plus icon 
.
Figure 11. Fragment of the Application parameter definition window for the Web Service protocol
In the interface that appears, you must enter the URL of the web service, i.e. the location of the WSDL file.
Figure 12. WSDL Location Indication Interface
Once validated, the specification contained in the WSDL is read.
Then, in the Name field, select an available item with the service name.
Figure 13. Service indication in the Name field
After selecting a service in the Name field, the following fields will be automatically filled in: Service, Endpoint, and the list of input and output parameters will be loaded in the Parameters table.
Figure 14. Example definition of Application parameters after indicating the service
In the Service field you can select one of the available services for the website
Figure 15. Selecting a service
Each time a service is selected, a list of input and output parameters is loaded. The input and output parameters of the service must be specified by filling in the Value column in the Parameters table.
Figure 16. Example definition of service parameters
-
The REST web service connector - REST web service can be called using predefined a Java class. We call it in JAVA protocol, specifying name and service giving the full name of a class:
pl.rodan.ooworkflow.environment.activity.CallRestService
An example of calling the REST service updating values of a process form is shown in Figure 17.
One must additionally specify values of the following input parameters:
- method - to specify the call method ['GET',’POST',’PUT',’DELETE']
- URL - to specify the call address along with parameters
- requestBody - to specify the call content, the JSON format should be maintained and Type output attribute :
- responseBody - to indicate the parameter in which the response of the service call will be placed in JSON format.
Figure 17. Example definition of connector parameters for REST service call
Figure 18 and Figure 19 show, respectively, the definition of the pre-action BPQL expressions setting the values of the Rest service parameters and the state of global variables in the process container.
Figure 18. Expressions setting the Rest service parameter values
Figure 19. The state of the global variables of the process after the service is executed
Assigning a task participant
Assigning a workflow participant is mandatory for tasks of the "User" and "Manual" types. Optionally, also for "Send" and "Receive" messages. BPQL expressions assign a Workflow Participant or multiple Workflow Participants to a task. The Work Participant Assignment interface is shown in Figure 20.
Figure 20. Definition of Participant for the task.
Selecting the One option means that the system will allow only one of the potential, i.e. selected by the BPQL expression, participants to perform the task at a time, after one of the participants has taken the task from the task list. The assignment algorithm is removing this task entry from the task lists of other selected users. Selecting the All option creates as task instances for all participants selected by the BPQL expression.
Ad-hoc task
Ad hoc tasks are executed according to the following rules:
- An Instance of the Ad hoc task is created when a token is received if it is connected to the graph of the surrounding process/sub-process via Incoming Flow(s). Otherwise, the instantiations of Ad hoc tasks occur at the time of the instantiation of the surrounding process/subprocess.
- The instantiation of all activities that do not have Incoming Flows occurs at the time of the instantiation of the subprocess containing them*.* For tasks of type " User " or " Manual " a list of participants is created according to the appropriate BPQL expression. Each of the designated Users can perform the assigned tasks multiple times*.*
- If the Ad hoc task is multi-instance, then each User who receives information about the task to their Task List can execute it any number of times. The Loop pointers sequential or parallel decide about the synchronization of instance execution, where in the first case the instances will be made available sequentially and in the second concurrently.
- The execution of each " User " task instance can be interrupted and resumed, respectively, by the " Save " or " Save and Close " service. In the latter case, the token will be sent after the appropriate outgoing transition if any.
- An Ad hoc task is terminated when all of its instances have been completed.
Subprocess
A subprocess, also called a composite activity, is a stand-alone element available within the process definition library that can be used both as a functional element of the process that includes it and/or as a stand-alone process of the highest level called by an external IT system. A subprocess appears in the graph of the process that includes it as a task symbol marked in the lower line of the description with a + sign
A classic example of such a software architecture is the process of document content recognition (Optical Character Recognition ). Recognition (OCR)), which is used to automate the recognition of various documents, for example invoices or notarial deeds, usually managed by different document flow processes. The definition of a subprocess includes its data, i.e. input and output parameters as well as global and local variables. Encapsulation of process/subprocess definitions results in complete isolation of their Data Containers.
Due to the location of the subprocess definition in the graph of the encompassing process, which creates the context of its instantiation through flow conditions, it can contain only one start event of the “None” type. Subprocesses can be nested at many levels. Communication of the nested processes is possible thanks to the exchange of parameters.
Figure 21 showing the definition fields of the process call shared in the library of available processes listed in the process design tool, which is to be made available as a subprocess within the higher-level process being defined*.* The link between the integrated process definition and the process/subprocess calling it is made via the library name of the former.
If the called process has defined input and/or output parameters, they will automatically be placed in the parameters field in the process tab of the calling process definition. For each of the parameters placed on the list, a BPQL expression using global variables should be added. This will create a mechanism for passing parameter values between the higher-level process and the subprocess called by it.
Figure 21. Calling an available process that handles a given subprocess
To define a new process input or output parameter in the process design tool:
- go to a given process in the process definition list panel
- go to the Container node, the right pane will display a list of currently defined process container attributes
- Select the menu item Container -> Add
- Enter parameter data, including:
- Name – provide a unique name. Basically, a string of alphanumeric characters starting with a lowercase letter is provided as the name. Each new word is appended to the existing ones and starts with a capital letter.
- Type – for the input parameter, select the value in. For the output parameter – the value out. If the given input parameter is also used as an output parameter (result), set the Type to in/out.
- Read Only – indicates that the parameter will be used only to read data and an error will occur when trying to write it. In the case of an input parameter, this parameter is automatically set to Read Only. In the case of an output parameter, this parameter should be left unchecked.
- Type - type of the attribute, select the appropriate type from the list of available types.
- Multi-value – if the parameter takes multiple values, this box should be checked,
- Mandatory – if the attribute value is always required, then this field should be checked. From a practical point of view, this option only makes sense for input parameters because most often the output parameter value is not known at the start of the process.
Ad hoc sub-process
The Ad hoc subprocess is applicable to cases where the basic requirement is to create a flexible environment to support group work. An example would be a collective project of creating a research report or software in which we have well-defined work stages performed by team members. In such cases, semantics based on sending tokens may be only partially applicable. The Ad hoc subprocess may or may not be associated with the process graph comprising it*.*
An Ad hoc process/subprocess definition can include flow elements such as activities, flows, gateways, and intermediate events. Token passing occurs between activities and intermediate events associated within the flow structure.
The following rules were adopted to control the execution of the Ad hoc subprocess :
- An Instance of the Ad hoc subprocess is instantiated when a token is received if it is connected to the graph of the surrounding process/subprocess via Incoming Flow(s). Otherwise, the instantiation of the Ad hoc subprocess occurs at the time of the instantiation of the surrounding process/subprocess.
- The instantiation of all activities that do not have Incoming Flows occurs at the time of the instantiation of the subprocess containing them*.* For tasks of the type User or Manual, a list of participants is created according to the appropriate BPQL expression. Each of the designated users can perform the assigned tasks multiple times*.*
- If Ad hoc tasks are multi-instance, each user receives information about the task to their task list. The loop markers sequential or parallel decide about the synchronization of the instance execution, where in the first case the instances will be made available sequentially and in the second concurrently. In the case of single tasks, retrieving a task from the task list causes its deletion from all other lists.
- The User type instance may be interrupted and resumed by the Service, as appropriate*.* Save or Save and Close buttons are available in the Task interface.. In the latter case its token will be sent after the appropriate outgoing transition if one exists.
- Activities that receive a token via an incoming flow are executed and in the case of tasks of type User or Manual the assignment of the participant is done according to the result of the BPQL expression. After the execution of such an activity is completed the token is sent after the outgoing flow or if it is not present it is consumed.
- The execution of an Ad hoc subprocess ends when there are no more tokens in its activities.
Event-driven subprocess
The Event-driven subprocesses are not related to the flow structure of the process that includes them. This means that such a subprocess is a separate graph placed within the model of the process/subprocess that includes it*.* The graph of an event-driven subprocess is surrounded by a named box with a dotted line and cannot be the source or destination of any Flow. Within the model of such a subprocess, all flow objects specified in BPMN 2.02 can appear, but it cannot have the boundary events.
An event-driven subprocess can contain only one initial catching event, which listens for its corresponding throwing event from the moment the enclosing process is instantiated.
Depending on the symbol used in the model, events may or may not interrupt the execution of the process/subprocess instance surrounding the subprocess they initiate. Instance of a subprocess can only occur when the surrounding process/subprocess is active, and it can occur multiple times, resulting in the creation of multiple concurrent instances.
An instance of the event-driven subprocess is created for each of the parallel events in the case of non-interrupting catching events. Due to their location within the scope of the invoking process/subprocess the event-driven subprocesses have access to the context of the enclosing process/subprocess. Execution of the enclosing process/subprocess is concurrent to the running instances of the event-driven subprocesses.
Starting interrupting events always cause only one instance of the event-driven subprocess. The context of the enclosing interrupted process/subprocess is available to the event handler during the completion phase to allow the event to be completed.
An event-driven subprocess may optionally re-trigger the event that triggered it to continue its handling outside of its surrounding process/subprocess via its appropriate boundary event.
Gateways
The Control activity is an element of the control flow definition used to perform activities in parallel, alternatively or optionally. When modeling a process we have two groups of gateways at our disposal*;* namely, the split flow gateways generating one or more tokens and controlling their ensuing flow and join gateways receiving one or more tokens and generating one token.
Flow gateways
| Symbol | Name | Description |
|---|---|---|
 | Event-driven gateway | The gateway configuration, unlike other types, does not depend on the values of the flow conditions defined in it. Its flow control depends on the configuration of events placed at the target ends of its outgoing flows.. |
 | AND Split gateway | The gateway creates multiple parallel paths by generating tokens according to the number of its outgoing flows without checking any conditional expressions. |
 | XOR flow gateway (XOR Split) | The Gateway creates one of the alternative paths within the configuration of its outgoing flows. The selected outgoing flow must satisfy the conditional expression assigned to it*.* If none of its outgoing flows satisfy the above requirement, the token is sent via the default outgoing flow if one is included in the Gateway configuration. |
 | OR flow gateway (OR Split) | The gateway creates multiple alternative paths as part of the configuration of its outgoing flows. The selected outgoing flow must satisfy the conditional expression assigned to it*.* If none of its outgoing flows satisfy the above requirement, the token is sent on the default outgoing flow, if one has been created. |
 | Complex flow gateway ( Complex Split) | The gateway generates at least one token for the selected outgoing flow of the gateway and at most one token for each outgoing flow. Both the selection of the appropriate outgoing flows and generation of tokens are executed by the BPQL expression created by the process designer. |
Table 5. Types of flow operators
A gateway is used to separate control. In the token terms, a gate consumes one token and generates one or more tokens depending on the type of the operator. The graphical representation of an operator is the bold boundaries of the diamond on the left. The operation of the flow gateways is described in Table 5.
Join gateways
The join gateway is used to join the flows. In terms of tokens, this operator consumes one or more tokens, depending on the type of operator and generates one token. There are three types of Gateways: AND Join, OR Join and XOR Join. The graphical representation of the operator is the bold boundaries of the diamond on the right. The operation of the join gateways is described in Table 6.
| Symbol | Name | Description |
|---|---|---|
 | AND gateway (AND Join ) | Tokens arriving on incoming flows to a parallel AND gateway are converted into one token sent on its outgoing flow only after all of them have been received. |
 | XOR Merge Gate ( XOR Join ) | Tokens satisfying the transition conditions arriving by incoming flows to an exclusive or merge (XOR) gateway are swapped for one token sent by its outgoing flow after receiving at least one of the incoming tokens. |
 | OR connection gate (OR Join ) | Tokens satisfying the transition conditions arriving on incoming flows to a merge (OR) gateway are converted into one token sent on its outgoing flow after all sent to it are received. |
Table 6. Types of join operators
Flows
A flow is a link between two activities indicating the order in which they are to be executed. A transition may have a condition. A conditional expression is defined as a BPQL rule. A flow activity is symbolically interpreted as a message in a form of a token between activities*.* The condition for a flow activity that has conditional expressions is that they return the true value. The Flow Types are presented Table 7.
| Symbol | Name | Description |
|---|---|---|
 | Flow (eng. Sequence) flow ) | The flow may or may not contain a conditional expression that controls the passing of the token between activities. |
 | Flow coming out of a task with a condition | A flow exiting a task is marked with a diamond if it contains a condition definition. |
 | Default flow | An implicit flow passes token between activities if the conditional expressions of all outgoing Transitions of a task evaluate to false. |
Table 7. Types of flows
Flow metadata definition panel (Figure 22) includes all of the elements necessary to execute it. Source and target activities are optionally identified by name and automatically by activity number in the process/subprocess graph.
The conditional expression symbolically controlling the transfer of the token is created in BPQL and is supported by the language expression editor according to the general rules adopted in the system. The condition is ignored if the flow has been marked with the Default checkbox*.*
The default flow marked with the appropriate checkbox is executed if all other transitions cannot be run due to the conditional expressions accepted in them.
Transition conditions are logical expressions that determine whether a given transition will be executed or not. A given condition is represented by a BPQL rule and can contain arbitrary language elements that ultimately evaluate to a Boolean type. In practice, a control flow condition is defined based on global process variables and BPQL functions that provide data on objects and forms evaluated by the process.
To define a condition, one must be on the Process Model tab, select the appropriate transition and double-click with the left mouse button. A dialog box for entering transition data appears on the screen. It provides the following information:
- From activity – the number and name of the starting activity from which the transition is defined. Read-only value.
- To activity – the number and name of the target activity to which the transition is defined. Read-only value.
- Name –the name of the transition. This name appears in the Process Model tab.
- Description – additional information about the transition, completed for documentation purposes.
- Condition – the BPQL expression.
When defining the transition condition, it is possible to insert logical operators: AND, OR, NOT using the buttons located in the lower left part of the window. To select global variable or built-in BPQL function, click the "Insert" button. A standard window for entering information about the organizational structure, built-in functions and global variables appears on the screen. In the Org. Structure tab, you can select four data categories:
- Function – a list of BPQL functions that can be used to define a condition appears on the screen. A function is selected by double-clicking on its name or by selecting the function and clicking the Select button
- Position – provides a list of positions defined in the system. This list may vary depending on the dictionaries of a given client.
- Group – allows you to select a functional group or organizational unit defined in the docuRob® WorkFlow system or synchronized with the appropriate employee management system.
- Employee - a list of employees employed in a given group or organizational unit selected from the drop-down list of groups and units.
Selection of a global variable is done on the second tab. After selecting it, a list of available attributes is displayed along with information about the type and kind of the variable. Double-clicking on a given variable selects it.
Figure 22. Flow object metadata
Other graphic symbols
The use of other graphical symbols within the process chart is discussed in Table 8.
| Symbol | Name | Description |
|---|---|---|
 | Swimlane | The intention of the BPMN 2.02 specification is to use the Role area to group tasks performed by the Process Users in a given role. For example, the Technologist role. This method of modeling in the the process graph substantially complicates maintaining the readability of the model. Therefore, we have introduced an alternative marking of tasks within the Role by appropriately assigning colours to the fills of their symbols. |
 | Data object | The introduction of Data Objects and their associations with tasks is important for conveying design information at the level of the conceptual process model created in the requirements analysis phase. Due to the data handling based on the process/subprocess data container, the symbols of Data Objects and their associations are not interpreted at the process execution level. |
 | Association | Association symbol is used to indicate an association between a Compensation boundary event and a compensating activity. |
 | Frame | The box denotes the scope of the event-driven subprocess graph, whose model is placed together with its surrounding process / subprocess. |
Table 8. Other graphic symbols
Examples
The presented examples are intentionally neutral from the application point of view and all activities included in it are marked with capital letters of the alphabet. The purpose of the example is to illustrate alternative methods of process modeling, i.e. control through the definition of the flow model and exercising control through logical operators provided in the Flow tab of the activity definition panel (Figure 23) or through the definition of gateway flows and connections (Figure 24).
Figure 23. Process definition with flows defined in the activity metadata
The presented alternative process models are generated by the process design tool of the docuRob® WorkFlow platform. The possibility of marking the roles of performers in tasks of the type User has been intentionally omitted. Figure 25 to Figure 28 illustrate the history of the execution of four different process flow models
Figure 24. Process definition with flows through Gateways
The executed runs of four pairs of process instances, created based on alternative models, differ in the logical values ( Boolean type ) global variables controlling the flows within both instances. The differences in the setting of the logical variable values in the execution variants of models 1-4 are shown in Table 9. For the subsequent run variants, only the rows that differ in relation to run variant 1 are shown.
Run 1 (Figure 25) was executed after introducing global variables with values "true" as input parameters of the invoked instances. Both expected parallel definition instance paths (AND gate) have been executed.
The difference between variants 1 and 2 of the execution of process pairs consists in assigning the value false to the logical variable $zn11 controlling the flow between activities A and B (Figure 23) or, in the case of the model based on gateways, between the Split OR gate and activity A (Figure 24). Blocking this transition resulted in the execution of only one process path in variant 2.
| Run | Action | In | Out | zn11 | zn12 | zn31 | zn32 | zn21 | zn22 | zn23 |
|---|---|---|---|---|---|---|---|---|---|---|
| 1 | Start | XOR | AND | T | T | T | T | T | T | T |
| A | OR | OR | T | T | T | T | T | T | T | |
| C | XOR | OR | T | T | T | T | T | T | T | |
| B | XOR | OR | T | T | T | T | T | T | T | |
| D | XOR | OR | T | T | T | T | T | T | T | |
| E | XOR | OR | T | T | T | T | T | T | T | |
| F | XOR | OR | T | T | T | T | T | T | T | |
| 2 | A | OR | OR | F | T | T | T | T | T | T |
| 3 | A | OR | OR | T | F | T | T | T | T | T |
| C | XOR | OR | T | T | T | F | T | T | T | |
| 4 | E | XOR | OR | T | T | T | T | T | F | T |
Table 9. Flow condition configurations in runs 1-4.
Run variant 3, with the logical variables $zn12 and $zn32 set to false, resulted in blocking the AND flow in both models and, accordingly, terminating both parallel process instance paths after executing activity instances (tasks) A and C.
Variant of run 4, when setting the value of the logical variable $zn22 to false, will skip the execution of action E.
The purpose of the example is, among other things, to show the functional equivalence of process instances based on alternative model definitions resulting in obtaining the same task execution paths.
Choosing a graph based on control activities (gateways) is a semantically richer alternative and seems more friendly to users responsible for automating business procedures based on the process architecture (business representatives).
In the case of using an internal definition of flows, we can expect increased efficiency of processing process instances (lower load on the server configuration) due to avoiding the workload resulting from running a larger number of control activity instances. This approach is undoubtedly better for processes containing mainly the automatic activities.
Figure 25. Run 1
Figure 26. Run 2
Within the process instances of the second run executed after the condition $zn11 =false was specified*,* the path <Start, C, B, D, E, F> was executed. The second parallel path was interrupted for both instances at the exit flow stage A. It is easy to see that the interruption of the parallel process path after the execution of the instance of the action A will cause tasks <B, D, E, F> to be executed once.
Figure 27. Run 3
The false values were specified for the logical variables $zn12 and $zn32. This configuration of flow conditions caused interruptions in both runs after the execution of tasks A and C. In the case of modeling the exit condition of task A, the default flow was used.
Figure 28. Run 4
In the fourth run, the value of the logical variable zn22=true was specified*,* which caused rejection with the entry condition for task E. In the instances of both models, this activity was not performed.